Use operator for in-repo e2e tests #10132
Conversation
marvin-tigera
added
release-note-required
caseydavenport
force-pushed
the
casey-use-operator
branch
from
227aaf4 to
8c71a7f
Compare
caseydavenport
added
docs-not-required
marvin-tigera
removed
release-note-required
caseydavenport
changed the title
caseydavenport
force-pushed
the
casey-use-operator
branch
from
9800862 to
c4bbbba
Compare
| build/_output/bin/gen-versions -os-versions=../calico_versions.yml > pkg/components/calico.go | ||
|
|
||
| # Modify pull policy to be "Never". | ||
| find . -name '*.go' | xargs sed -i 's/PullIfNotPresent/PullNever/g' |
caseydavenport
changed the title
caseydavenport
force-pushed
the
casey-use-operator
branch
from
f48cc23 to
b4f5686
Compare
| # the test manifest. | ||
| includeCRDs: false | ||
| goldmane: | ||
| enabled: false |
There was a problem hiding this comment.
We've had a lot of recent failures just installing with these components. I expect that will slow down a lot once they're not being as actively tweaked, but I wonder if (as long as they don't blow our compute budget) we should enable them so they're there through the tests?
There was a problem hiding this comment.
Yeah! I was planning on doing this as a part 2 follow-on, but could certainly enable from the get-go.
| wait_pod_ready -l k8s-app=kube-dns -n kube-system | ||
| wait_pod_ready calicoctl -n kube-system | ||
| echo "Calico is running." |
There was a problem hiding this comment.
Could we easily check the tigerastatus instead of relying on pod readiness?
Doesn't have to be included in this PR, but I think it would be better?
There was a problem hiding this comment.
Yeah, we could do that instead pretty easily.
| @@ -0,0 +1,48 @@ | |||
| # Components defined here are required to be kept in sync with hack/gen-versions/calico.go.tpl | |||
There was a problem hiding this comment.
Specify "in the tigera/operator repo"; also reference the other spot in the operator repo that's the direct copy paste (config/calico_versions.yml), and update both of those files to refer back here please.
That said, I hope we can remove this copy of this file and will comment elsewhere on that.
| # Modify the versions that are in-use to match our locally built images. | ||
| pushd operator | ||
| make build/_output/bin/gen-versions | ||
| build/_output/bin/gen-versions -os-versions=../calico_versions.yml > pkg/components/calico.go |
There was a problem hiding this comment.
I'm wondering if there's a practical way to generate this file from tigera/operator:config/calico_versions.yml.
As it stands there are only relatively minor variations from that file (mostly master vs latest-amd64 but it's not quite a simple swap).
For older branches it's also a little annoying: the operator tends to pin a release version (e.g. v3.28.2), but I guess the intention here is to always use the latest-amd64 tag regardless of what branches are in use? Might be clearer to swap everything to test-build if that's the case?
There was a problem hiding this comment.
yeah, the intention is that the version we build is always going to install the latest images that were built as part of the CI / commit under test.
I think this will work for release-branches as well. We could change how we build / tag images for CI so that they match the ones expected for the operator that is being pulled in - that would allow us to remove this I think?
Well-worth doing IMO, but I think that's a phase 2 task.
Description
Related issues/PRs
Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.